ICTSC2018 インフラ解説
ICTSC2018 インフラ解説
はじめに
今回のインフラを担当したnasuです。
みなさん１年間コンテストに参加してくださってありがとうございました。
今回のコンテストも楽しんでいただけたでしょうか。
また1日目のコンテストサイトの停止などご迷惑をおかけして申し訳ありませんでした。
引き続き運営委員も改善していきたいと考えています。
今回も引き続き機材提供してくださいました企業様、新規で機材提供して頂いた企業様
誠にありがとうございました。お陰様で無事開催ができ、運営学生もインフラ技術を学ぶことができました。
さてこの記事はインフラ解説記事です。
前回も解説記事は書いたので、トラコンバックボーンについてなどの概要は省き
今回は前回とは違う内容を中心に書いていきたいと思います。
ですので前回作成した解説記事も併せて読んで頂けると幸いです。
また以下のスライドは１日目の懇親会の時にお見せしたスライドです。
各々の説明
MX5
今回は対外用ルータとしてJuniper MX5をお借りしました。
Juniper MX5は高機能なルータで主に大規模なネットワークで使われています。
MX5はModular Interface Cards(MIC)スロットというものがあり、そこに利用用途に応じてMICを搭載して利用します。
今回はIX3110とQFX5100を、SFPモジュールを利用して接続したかったのでMIC-3D-20GE-SFPを搭載しました。
利用用途としてHomeNOC様(AS59105)とピアを貼り外部への通信と、内部のルーティングを行っています。
またMX5単体ではStatic NATしかサポートされていなく、PATを使うにはMultiservices MICというMICを取り付ける必要があります。
そのため今回はNAPTを行う為に一旦IPv4の通信はIX3110に折り返させて、IX3110でNAPTを行う必要があり、フルルートを持ったグローバルのルーティングテーブルと内部のルーティングテーブルとを分ける必要がありました。
QFX5100
前回に引き続きJuniper QFX5100を2台お借りしました。
今回サーバにはSFPのNICカードが無かったため、QFX5100の方にSFP-1GE-Tのトランシーバを付けRJ45で接続しました。
また２台ありますが論理的に１台の構成(Multi Chassis)は行わずに、別々のSWとして利用し自作仮想基盤n0stackのノードを半々に分けて接続しています。
そして各チームをVRFで分けて運用しQFX5100両機に同じチームのVRFを展開し外に行く通信はNAVTを経由しています。
VRFの運用とトラコン技術のNAVTとついては前回の解説記事のQFX5100編に詳しく書いてあるのでそちらを御覧ください。
この構成ではQFX5100の両機にTeam01のVRFが存在していて、何もしなかったらお互いのVRFは通信を行うことができません。
それをQFX5100をPEルータとしてMP-BGP L3VPNを利用してお互いのVRF間の通信を行っています。
今回インフラでは特にテーマというものは決めませんでしたが、Segment Routingに挑戦してみたいという話しがありました。
今回挑戦したのはSegment Routing MPLSの方です。
Segment Routing MPLSとはIGPでラベル交換を行うことができセグメントによってラベルパスを表すことができます。
Segment Routing MPLS(以下SR)の利点は主に以下の通りです。
– IGPでラベル広告を行えることで実装が楽
– LDP, RSVPを使った従来のMPLSより設定、操作がシンプルで運用が楽
– SR-TE ECMPがサポートされている
– TI-LFAは複雑なトポロジの障害でもバックアップパスを用意することができる
Segment Routing詳細は下記のURLに詳しくスライドがございますのでぜひ御覧ください。
JANOG40 Meeting in Fukushima Segment Routing チュートリアル
今回はシンプルに４台あるのでIGPを使ってラベル広告をし4つのノードを明示的に以下のようなパス選択をするつもりでした。
Primary
– QFX5100-01 → MX5-01 → MX5-02 → QFX5100-02
Backup
– QFX5100-01 → MX5-02 → QFX5100-02
しかしパス選択のところで上手く設定ができず検証期間が過ぎていき実際本番では最短のQFX5100-01とQFX5100-02間で通信していてSR-TEはできていません。
監視
今回運営として主に監視系の構築を行いました北澤です。
今回は前回・前々回大会の電源トラブルの反省を元に、監視基盤をさくらのクラウド上のサーバに構築し、会場とVPNを貼ることで監視を行いました。
これにより、万が一電源トラブル等でサーバ全台が落ちてしまった場合も監視系は落ちないため、サーバ落ちる直前までのメトリクスを元に問題の解決を行うことが出来ると考えました。
また、今大会ではログやメトリクスの収集を行うサーバの負荷分散と冗長化を目的に、収集サービスやDBを全てコンテナ化しKubernetes上で動作させました。
監視構成は以下になります。
Prometheus、Zabbixともに監視項目に異常が起きた際にはSlackに通知を行うようにしました。これにより、実際に二日目開始直前にVMが落ちていたトラブルを発見し、VMを再起動することで問題なく二日目を迎えることができました。
収集したメトリクスを表示するGrafanaでは以下のようなダッシュボードを作成しました。
サーバ全体を俯瞰するダッシュボードと個々のサーバを見るダッシュボードを用意することで、サーバに以上が生じた際に目で見てどの時間に何が起きているのかを把握しやすくしました。
今年の監視系のまとめとして、去年までサーバに直接インストールしていたサービスを全てKubernetes上で動作させることができました。課題点として、KubernetesのPersistentVolumeとKubernetes上で動作するDBの冗長化が行えていないため、来年以降はこれらにも取り組むことが出来れば良いと考えています。
無線LANについて
今回は無線LAN環境を提供するために以下の機材をお借りしました。
– Cisco 5508 Wireless Controller
– Cisco AIR-AP-3802I-Q-K9 5台
今回もみなさんにはICTSC2018というSSIDにユーザ名、パスワード認証で各チームのネットワークに接続してもらいました。
Cisco WLCの設定とRadius認証については前回の記事で解説していますのでそちらを御覧ください。
前回と大きく異なる点は会場と2.4Ghzを提供しなかった点です。
会場のNTT調布研修センターは周りにビルや無線LANを飛ばす施設等が無いため、5Ghz帯は混雑はしていませんでした。
またホットステージ・コンテスト中はDFSを一切受けず無線的にはとても快適な会場でした。
DFSにほぼ気をつける必要が無かったため、急に接続してるチャンネルが変更して通信が途切れるということはありませんでした。
また2.4Ghz帯の提供を干渉されやすい・トラブルの元という観点から提供を行いませんでした。
その為2.4Ghzしか使えないパソコンをお持ちの参加者の方には有線ケーブルでの接続をお願いしました。
これによりほぼ全てのユーザがIEEE802.11acで繋ぐことができ安定し高速な無線環境を提供することができました。
アンケート結果からも前回の比で比べると不便だったというだったという方は10%減りました。
しかし一部の端末で時間が経つと接続が切れるという事象が報告されており、運営側ですぐ再現・原因究明ができなかったため、接続が不安定な方には有線接続をお願いしました。
接続が途切れてしまった方にはご迷惑をおかけしました。
まとめ
今回もバックボーンネットワークには様々な技術を使って構築しました。
様々な技術を使っての構築は難しいですが、運営にとって問題を提供しやすい環境、参加者が快適に問題が解ける環境を追い求め挑戦していきたいです！
そしてトラブルシューティングコンテスト2019開催決定しています！
ぜひ次回もみなさんからの参加お待ちしております！